Identity management in its widest sense means management of all the personal information about a person, including at least all the person's digital relations. Over the next decade, identity management systems in this wide sense are likely to evolve. Short-term, identity management is typically said for web single sign-on with the transfer of a small amount of data about a person.
The main business case is a general boost of electronic business: Identity management is an infrastructure issue where a standard, like the Internet and web standards, may benefit almost all parties.
Single sign-on enables a person or user to log in to different organizations or services while remembering only one password. Furthermore, single sign-on protocols allow client applications to identify themselves to other applications with whom they had not a priori exchanged any common data, such as keys. Usually, many users choose the same username and password with all the organizations or services. There are two problems with this: Each service can impersonate the user towards the others. This may be acceptable for the services of one enterprise, but even there one would prefer better modularization. And clearly it is not acceptable for a user's overall web experience.
Single sign-on is widely seen as a necessary infrastructure to make electronic business on the Internet easier and to allow widespread use of the emerging Web Services. It may also evolve into more general identity management, e.g., for exchanging additional information about a person once the identity has been established.
Recently, single sign-on solutions are known, for example, by Microsoft Corporation's Passport system (URL: http://www.passport.com), by the OASIS (Organization for the Advancement of Structured Information Standards) standardization of the Security Assertion Markup Language (SAML) (URL: http://www.oasis-open.org/committees/security/docs), and the Liberty Alliance Project's recent specifications (URL: http://www.projectliberty.org). An aspect in the Liberty specifications is that detailed protocols are provided not only for browsers as client applications, but also more efficient protocols for other, more powerful client applications. Older related schemes in this setting are classical three-party authentication protocols.
Classical three-party client authentication protocols like Kerberos, Needham-Schroeder all start with a key-exchange or key-establishment protocol and then require the client application to use this key for encryption and authentication. In other words, a third party that can identify the client application by some a-priori exchanged information, such as a password, secret key, or confirmed public key, typically generates a new secret key for communication between the client application and its partner entity, which herein is called “requesting entity”, and establish this secret key securely to both these entities. There is a great variety of protocols for carrying out this secure transfer of the secret key.
Federated identity management proposals such as the Security Assertion Markup Language (SAML) enable a reduction of user management costs by savings in password helpdesks, user management, and user deletion. SAML features browser-based profiles that only rely on a standard web browser to carry out identity federation, e.g., by means of single sign-on. These protocols complement the general advantages of federated identity management solutions with the property of being zero-footprint, i.e., not requiring installation of additional client software. Therefore, browser-based profiles are cost-efficient to deploy. However, designing secure protocols with a standard web browser as the client is not trivial. The browser, not being aware of the protocol it participates in, has a predefined behavior, reacts to predefined messages and generates information flow both to the underlying operating system and to communication partners. Especially the security of protocols that transfer confidential information through a browser's Uniform Resource Location (URL) is put at stake by this protocol-unaware behavior of a standard web browser. The browser/artifact profiles of SAML belong to this class of protocols, because they issue a random artifact as reference to a security token and transport it via the browser redirect URL.
In the meantime, SAML has advanced to Version 2.0. The structure and naming in the standards has also slightly changed, hence the corresponding protocol (in the terminology of security protocol research) is now the SAML V2.0 Web Browser SSO/Response/Artifact Feature.
It is an object of the invention to provide improved solutions for identity management.